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Abstract 

A  logic  for  reasoning  about  timing  properties  of  concurrent  programs  is  presented.  The  logic 
is  based  on  Hoare-style  proof  outlines  and  can  handle  maxima!  parallelism  as  well  as  certain 
resource-constrained  execution  environments.  The  correctness  proof  for  a  mutual  exclusion 
protocol  that  uses  execution  timings  in  a  subtle  way  illustrates  the  logic  in  action.  A  soundness 
proof  using  structural  operational  semantics  is  outlined  in  the  appendix. 

Key  words:  concurrent  program  verification,  timing  properties,  safety  properties,  real-time 
programming,  real-time  actions,  proof  outlines. 

1  Introduction 

A  safety  property  [9]  of  a  program  asserts  that  some  proscribed  “bad  thing”  does  not  occur  during 
execution.  To  prove  that  a  program  satisfies  a  safety  property,  one  typically  employs  an  invariant,  a 
characterization  of  current  (and  possibly  past)  program  states  that  is  not  invalidated  by  execution. 
If  an  invariant  I  holds  in  the  initial  state  of  the  program  and  /  =>  Q  is  valid  for  some  Q.  then 
-'Q  cannot  occur  during  execution.  Thus,  to  establish  that  a  program  satisfies  the  safety  property 
asserting  that  ->Q  does  not  occur,  it  suffices  to  find  such  an  invariant  I. 

Timing  properties  are  safety  properties  where  the  “bad  thing”  involves  the  time  and  program 
state  at  the  instants  that  various  specified  control  points  in  a  program  become  active.1  Timing 
properties  can  concern  externally  visible  events,  like  inputs  and  outputs,  as  well  as  events  and  data 
that  are  internal  to  a  program,  like  the  value  of  a  variable  or  the  time  that  a  particular  command 
starts  or  finishes.  For  example,  in  process  control  applications,  the  elapsed  time  between  a  stimulus 
and  response  may  have  to  be  bounded.  This  is  a  timing  property  where  the  “bad  thing”  is  defined 
in  terms  of  the  time  that  elapses  after  one  control  point  becomes  active  until  some  other  control 
point  does.  Timing  properties  concerning  internal  events  are  useful  in  reasoning  about  ordinary 

*A  preliminary  version  of  this  work  appeared  in  Real-time:  Theory  and  Practice ,  Proceedings  of  REX  workshop. 
June  1991,  Springer- Verlag  Lecture  Notes  in  Computer  Science,  volume  600. 

^Supported  in  part  by  the  Office  of  Naval  Research  under  contract  N00014-91-J-1219,  the  National  Science  Foun¬ 
dation  under  Grant  No.  CCR-8701103,  DARPA/NSF  Grant  No.  CCR-9014363,  and  a  grant  from  IBM  Endicott 
Programming  Laboratory. 

Supported  in  part  by  NSF  grant  CCR-9003441. 

^Supported  in  part  by  Defense  Advanced  Research  Projects  Agency  (DoD)  under  NASA  Ames  grant  number  NAG 
2-593,  and  by  grants  from  IBM  and  Siemens. 

‘Informally,  the  active  control  points  at  any  instant  are  determined  by  the  values  of  the  program  counters  at  that 
instant.  See  [15]  for  a  more  formal  definition. 
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concurrent  programs  that  exploit  knowledge  of  command  execution  times  to  coordinate  processes. 
One  such  protocol— for  mutual  exclusion — is  given  in  section  4. 

Because  timing  properties  are  safety  properties,  the  invariant- based  method  outlined  above  for 
reasoning  about  safety  properties  can  be  used  to  reason  about  timing  properties.  This  means  that 
a  programming  logic  L  to  verify  (ordinary)  safety  properties  can  form  the  basis  for  a  logic  /,'  to 
verify  timing  properties.  It  suffices  that  in  L‘  we  are  able  to: 

(a)  specify  in  /  and  Q  information  about  tiie  times  at  which  events  of  interest  occur  and 

(b)  establish  that  program  execution  does  not  invalidate  such  an  /. 

Point  (a)  means  that  in  defining  V ,  the  language  of  L  might  have  to  be  extended  so  that  it  becomes 
more  expressive.  Point  (b)  means  that  the  inferencing  apparatus  of  L  might  have  to  be  refined 
so  that  /  can  be  proved  an  invariant  for  a  program  whose  semantics  includes  information  about 
execution  timings. 

A  logic  for  timing  properties  will,  of  course,  depend  on  the  execution  model  for  programs.  Like 
[14],  we  consider  two  kinds  of  actions,  ordinary  actions,  which  can  take  any  amount  of  time  to 
execute,  and  reat-tim:  actions,  which  have  constant  upper  and  lower  bounds  on  their  execution 
time.  Real-time  actions  allow  the  mocmlling  of  schedulers  typically  found  when  multiprogramming 
is  employed  to  implement  processes. 

This  paper  describes  extensions  to  a  logic  of  proof  outlines  [15]  to  enable  verification  of  timing 
properties  for  concurrent  programs.  The  approach  taken  is  the  one  just  outlined:  we  start  with 
a  logic  for  proving  ordinary  safety  properties,  augment  the  language  according  to  (a)  and  refine 
the  inference  rules  according  to  (b).  The  presentation  is  organized  as  follows.  In  Section  2  we 
describe  Proof  Outline  Logic  for  non-real-time  programs.  Then,  in  Section  3.  we  describe  additional 
mechanisms  needed  to  handle  real  time.  In  particular,  we  describe  changes  that  must  be  made  to 
the  Rule  of  Consequence  and  to  the  definition  of  non-interference.  In  Section  4,  we  illustrate  the 
use  of  our  logic  on  a  mutual  exclusion  protocol.  Section  5  contains  discussion  of  related  topics. 

An  appendix  summarizes  a  Plotkin-style  [13]  structural  operational  semantics  and  soundness 
proof.  The  full  details  of  the  soundness  proof  will  appear  in  [2].  Our  proof  builds  a  natural  model, 
similar  to  models  built  by  other  researchers  in  the  theory  of  concurrent  programming  languages[6. 
18,  1,  13].  This  method  of  construction  aigues  for  the  reasonability  of  the  logic  and  language  as 
well  as  proving  its  soundness,  in  much  the  same  way  that,  for  example,  having  the  integers  as  a 
model  of  an  arithmetic  system,  or  the  Scott  models  for  a  A-calculus,  give  more  plausibility  than  a 
term  model  does. 

2  Ordinary  Proof  Outline  Logic 

In  order  to  reason  about  a  program,  we  must  be  able  to  characterize  sets  of  program  states  and 
reason  about  them.  First-order  predicate  logic  is  an  obvious  choice  for  this  task,  and  we  employ 
the  usual  correspondence  between  the  formulas  of  the  loeic  and  the  programming  language  of 
interest — each  variable  and  expression  of  the  programmin'.;  language  is  made  a  term  of  the  logic 
and  each  Boolean  expression  of  the  programming  language  is  made  a  predicate  of  the  logic.  It  will 
be  convenient  to  assume  that  piedicates  and  terms  are  always  defined,  although  the  value  of  a  term 
may  be  unspecified  in  some  states.  For  example,  we  will  assume  that  the  term  x/y  has  a  value 
whatever  value  y  has,  but  that  y  x  (x/y)  need  not  equal  when  y  is  0  because  the  value  of  x/y  is 
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unspecified  in  such  states.2 

Predicates  and  function  symbols  for  the  programming  language's  data  types  provide  a  wav  to 
express  facts  about  program  variables  and  expressions.  Type  declarations  in  the  program  induce 
axioms  concerning  the  values  that  may  be  assumed  by  the  variables  they  declare.  For  simplicity, 
we  take  these  as  given. 

The  state  of  a  program  also  includes  information  that  tells  what  atomic  actions  might  be 
executed  next.  For  representing  this  control  information,  we  fix  some  predicate  symbols,  called 
control  predicates,  and  give  axioms  to  ensure  that,  as  execution  proceeds,  changes  in  the  values  of 
the  control  predicates  correspond  to  changes  in  program  counters.  (An  alternative  representation 
would  have  been  to  define  a  “program  counter”  variable  and  a  data  type  for  the  values  it  can 
assume.) 

2.1  Control  Predicates 

A  program  is  a  structured  collection  of  labelled  commands ,  although  we  omit  labels  in  program 
texts  unless  they  are  needed.  Each  command  comprises  one  or  more  atomic  actions.  The  defining 
characteristic  of  an  atomic  action  is  that  its  execution  is  performed  as  a  single  indivisible  state 
transformation.  The  control  points  of  a  program  are  defined  by  its  atomic  actions.  Each  atomic 
action  has  distinct  entry  and  exit  control  points.  For  example,  the  atomic  action  that  implements 
skip  has  a  single  entry  control  point  and  a  single  exit  control  point;  the  test  for  an  if  has  one  entry 
control  point  and  multiple  exit  control  points,  one  for  each  alternative.  Execution  of  an  atomic 
action  u  can  occur  only  when  an  entry  control  point  for  a  is  active.  Among  other  things,  execution 
causes  that  active  entry  control  point  to  become  inactive  and  an  exit  control  point  of  a  to  become 
active. 

For  each  command  or  atomic  action  5,  we  define  the  following  control  predicates: 

at(S):  an  entry  control  point  for  5  is  active. 

after(S):  an  exit  control  point  from  S  is  active. 

in(S ):  at(S')  holds  for  some  atomic  action  comprising  5. 

The  various  commands  of  a  programming  language  give  rise  to  a  set  of  axioms  relating  these 
control  predicates.  These  axioms  formalize  how  the  control  predicates  for  a  command  or  atomic 
action  S  relate  to  the  control  predicates  for  constructs  comprising  5  and  constructs  containing  S , 
based  on  the  control  flow  defined  by  S.  For  our  programming  language  these  axioms  are  given  in 
Figure  1.  We  use  GEvaljf(S)  there  to  denote  the  guard  evaluation  action  for  an  if  with  label  5  and 
GEvald0(5)  to  denote  the  guard  evaluation  action  for  a  do  with  label  5.  Equality  of  Boolean  values 
is  logical  equivalence.  And,  we  write  Pi©P2®  •  •  •  ©■£*„  to  denote  that  exactly  one  of  Pt  through  Pn 
holds. 

Our  programming  language  is  based  on  guarded  commands  [3].  Sequencing  is  written  without 
the  traditional  semicolon  separator.3  The  guard  evaluation  of  the  if  command  atomically  evaluates 
all  its  tests  at  once  and  selects  a  branch  for  which  the  test  is  true;  if  none  are  true,  then  it  will  block 
until  some  test  is  made  true  by  another  process.  A  do  command  atomically  evaluates  its  tests, 
selects  a  branch  with  a  true  test,  and  repeats;  if  none  are  true,  then  it  exits.  A  cobegin  command 

JMore  formally,  we  admit  any  interpretation  in  which  a/6  is  interpreted  as  a  divided  by  6  when  6  ?£  0,  and  has 
arbitrary  values  otherwise. 

3 We  shall  later  see  that  this  avoids  a  problem.  A  semicolon  sepa-  >r  would  have  to  occupy  the  same  position  as 
an  assertion  in  the  standard  textual  representation  of  the  proof  outi,  < 
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starts  all  of  its  component  processes  simultaneously,  executing  them  concurrently.  When  they  all 
finish,  the  cobegin  finishes  as  well. 
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Figure  1:  Control  Predicate  Axioms 


2.2  Syntax  and  Meaning  of  Proof  Outlines 

A  proof  outline  PO(S )  for  a  program  or  atomic  action  5  is  a  mapping  from  the  control  predicates 
of  5  to  assertions.  Each  assertion  is  a  Predicate  Logic  formula  in  which 

•  the  free  variables  are  program  variables  (typeset  in  italics)  or  rigid  variables .  (typeset  in 
uppercase  roman),  and 

•  the  predicate  symbols  are  control  predicates  or  the  predicates  of  the  programming  language's 
expression  language. 

Assertions  in  which  all  terms  are  constructed  from  program  variables,  rigid  variables,  and  predicates 
involving  those  variables  are  called  primitive  assertions. 

If  T  is  a  subprogram  of  5  and  some  PO(S )  is  fixed,  then  we  write  pre(T)  (resp.  post(r))  for  the 
assertion(s)  that  PO(S)  associates  with  at(T)  (resp.  af:.  r'T ));  these  are  called  the  precondition 
and  postcondition  of  T.  For  the  proof  outline  in  Figure  2,  this  correspondence  is  summarized  in 
Figure  3.  In  it,  a;  is  a  program  variable  and  X  is  a  rigid  variable.  All  assertions  except  pre(S)  and 
postf.?)  are  primitive. 

Proof  outlines  are  generally  represented  as  texts  containing  the  program  S  and  an  assertion  in 
braces  before  and  after  every  subprogram  of  S.  For  our  programming  language,  this  will  associate 
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{x  —  X  A  at(S)} 

S:  if  x  >  0  —'{x  =  X  A  x  >  0} 

5]  :  skip 
{x  =  X  A  x  >  0} 
jj  x  <  0  —  {i  =  X  A  x  <  0} 

:  x  :=  -x 

{-x  =  X  A  -x  <  0} 

fi 

{x  =  |Xj  A  after(S)} 


Figure  2:  Computing  |x 


at  least  one  assertion  with  every  control  predicate  of  a  program.  Multiple  control  predicates  may 
be  mapped  to  the  same  assertion,  as  illustrated  by  the  proof  outline 

{P}x:=l  {Q}y:=2{R}.  (1) 

Here,  the  entry  control  point  for  program  x  :=  1  y  :=  2,  and  the  entry  control  point  for  x  :=  1  map 
to  the  same  assertion,  P.  This  is  reasonable,  because  at(“x  :=  1  y  2”)  and  «t(“x  :=  1”)  are 
equivalent;  if  one  control  point  is  active,  so  will  be  the  other. 

Finally,  for  a  proof  outline  PO(S),  we  write  pre(  P0(S))  to  denote  pre(S),  post(PO(S))  to 
denote  post(S),  and  use  a  triple  {P}  PO(S )  {Q}  to  specify  the  proof  outline  in  which  pre(S)  is  P. 
post(S)  is  Q,  and  all  other  pre-  and  postconditions  are  the  same  as  in  PO(S). 


Assertion 

Assertion  Text 

pre(S) 

i  =  XA  at(S) 

post(S) 

x  =  |X|  A  after{S) 

pre(5i) 

x  =  X  A  x  >  0 

post(Si) 

x  =  X  A  x  >  0 

pre(52) 

x  =  X  A  x  <  0 

post(52) 

—x  -  X  A  -x  <  0 

Figure  3:  Assertions  in  a  Proof  Outline 


Validity  of  Proof  Outlines 

The  assertions  in  a  proof  outline  are  intended  to  document  %vhat  can  be  expected  to  hold  of 
the  program  state  as  execution  proceeds.  The  proof  outline  of  Figure  2.  for  example,  implies  that 
if  execution  is  started  at  the  beginning  of  Si  with  x  =  23  (a  state  that  satisfies  pre(Si)).  then  if 
5i  completes,  post(5i)  will  be  satisfied  by  the  resulting  program  state,  as  will  post(5).  And  if 
execution  is  started  at  the  beginning  of  S  with  x  =  X.  then  whatever  assertion  is  next  reached — be 
it  pre(Si)  because  X  >  0  or  pre(S2)  because  X  <  0 — that  assertion  will  hold  when  reached,  and 
the  next  assertion  will  hold  when  it  is  reached,  and  so  on. 

With  this  in  mind,  we  define  validity  of  assertions  and  proof  outlines.  A  valid  assertion  P 
is  one  that  holds  in  all  program  states,  viz.,  states  satisfying  the  datatype  and  control  predicate 
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{true} 

a:  cobegin 

{i  =  l} 
b:  skip 

// 

c:  skip 

{...} 

coend 


Figure  4:  Multiple  Active  Control  Points  (Partial  proof  outline) 

axioms.  A  valid  proof  outline  PO(S)  will  be  one  that  describes  a  relationship  among  the  program 
variables  and  control  predicates  of  S  that  is  invariant  and,  therefore,  not  falsified  by  execution  of 
5.  The  invariant  defined  by  a  proof  outline  PO(S )  is  “if  a  control  predicate  cp  is  true,  then  so  is 
every  assertion  that  PO(S)  associates  with  cp”  and  is  formalized  as  the  proof  outline  invariant  for 
PO(S)-. 

Ipo(S)  ■  A  ((a<(T)  =►  P re(T))  A  ( after (T)  =>  post(T))) 

T 

where  T  ranges  over  the  subprograms  of  S.  For  example,  the  proof  outline  invariant  defined  by 
PO{S )  of  Figure  2  is: 

at(S)  =>  (x  =  X  A  at(S))  A  after(S)  =>  (x  —  |X|  A  after{S)) 

A  at(Si)  =>  (x  =  X  A  x  >  0)  A  after(Si)  =>  (x  =  X  A  x  >  0) 

A  at(Si)  =>  (x  =  X  A  x  <  0)  A  after(S2)  =>  (— x  =  X  A  —  x  <  0) 

Notice  that  proof  outline  validity  is  with  respect  to  executions  starting  in  any  state,  even  a 
state  in  the  middle  of  the  program.  For  example,  the  proof  outline 

{x  =  0  A  y  =  1} 

S:  a  :  x  :=  x  +  2 
{x  =  2} 
b  :  y  :=  y  4-  2 

{x  =  2  A  y  =  3} 

is  not  valid.  This  is  because  a  state  where  at(b),  x  -  2,  and  y  -  20  hold  satisfies  /pops),  but 
starting  execution  in  this  state  leads  to  one  that  does  not  satisfy  Ipo(S)- 

In  order  to  make  the  inference  rules  of  our  logic  as  easy  to  use  as  possible,  we  have  designed 
them  so  that  hypotheses  concerning  proof  outlines  do  not  delve  too  deeply  into  the  structure  of 
those  proof  outlines.  Allowing  multiple  control  predicates  to  be  true  simultaneously  -  as  we  do 
complicates  the  realization  of  this  goal.  Consider  the  concurrent  program  of  Figure  4.  There.  at{a) 
is  true  iff  both  at(b)  and  at(c)  are  true.  Thus,  in  Figure  4.  ;f  at(a)  and  lpo(S)  are  both  true,  then 
x  =  1  holds.  However,  pre(a)  gives  no  warning  of  this  requiiement:  it  is  tiie  trivial  assertion  “true". 
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To  avoid  such  anomalies,  we  insist  that  a  proof  outline  PO(S)  give  its  requirements  in  its 
precondition.  If  at(S)  and  pre(  PO(S))  hold,  then  Ipo(S)  must  hold  as  well.  We  call  such  proof 
outlines  self-consistent,  and  require  self-consistency  of  a  valid  proof  outline  along  with  invariance 
Ipo(S)- 

These  invariance  and  self-consistency  requirements  for  proof  outline  validity  can  be  formalized 
in  terms  of  Hg -validity  of  Temporal  Logic  formulas,  where  ' H 5  contains  all  infinite  state  sequences 
constructed  by  executing  programs  C[S]  that  contain  a  copy  of  S.  The  elements  0  of  Tif  are  those 
infinite  sequences  of  states  such  that: 

•  <70  is  a  state  reached  by  executing  some  program  (7[5j  zero  or  more  steps  from  its  initial  state, 
and 

•  each  state  cr,+ j  is  a  possible  result  of  performing  an  atomic  action  of  S  from  state  a,,  or.  if 
no  action  of  S  is  enabled,  repeating  o;. 

Note  that  Tig  J=  P  denotes  that  a  Predicate  Logic  formula  P  is  valid,  because  every  program 
state  is  the  first  state  of  some  sequence  in  Tig.  We  now  define  PO(S)  to  be  vatid  if  and  only  if 


Invariance:  Ti^  (=  i/>0(S)  =*  nbo(S) 

Self-Consistency:  Tig  £=  ( at(S )  A  pre(S))  =>  Ipo(s ) 

From  this  definition  we  see  that  values  of  rigid  variables  are  the  same  throughout  any  execution, 
because  free  rigid  variables  in  a  temporal  logic  formula  are  implicitly  universally  quantified.  This 
means  that  rigid  variables  in  proof  outlines  can  be  used  relate  the  values  of  program  variables  from 
one  state  to  the  next.  For  example,  the  proof  outline  of  Figure  2  is  valid  and  employs  a  rigid 
variable  X  to  record  the  initial  value  of  x.  Starting  execution  in  a  state  where  at(S2)  and  x  —  -23 
holds  will  satisfy  Ipo(S)  =>  °bo(S)  even  if  X  is  41  rather  than  —23  because  then  Ipo{S)  is  not 
satisfied  (causing  Ipo(S)  =*■  to  trivially  satisfied). 

2.3  Axiomatization  for  a  Proof  Outline  Logic 

Proof  Outline  Logic  is  an  extension  of  Predicate  Logic.  The  language  of  Predicate  Logic  is  extended 
with  proof  outlines  for  all  atomic  actions,  commands,  and  programs.  The  axioms  and  inference 
rules  of  Predicate  Logic  are  extended  with  axioms  and  inference  rules  that  allow  only  valid  proof 
outlines  to  be  proved  theorems.  In  particular,  there  are  some  command-independent  inference 
rules  as  well  as  an  axiom  or  inference  rule  for  each  type  of  command  and  atomic  action.  The 
command-independent  rules  appear  in  Figure  5.  With  one  minor  exception,  they  will  apply  in  our 
real-time  setting  as  well.  We  now  turn  to  the  axiomatization  for  a  guarded-command  concurrent 
programming  language. 

The  skip  command  is  a  single  atomic  action  whose  execution  has  no  effect  on  any  program 
variable.  Thus,  it  leaves  primitive  assertions — which  only  mention  program  variables  and  terms 
that  by  their  nature  cannot  change — unchanged. 

skip  Axiom:  For  a  primitive  assertion  P:  {P}  skip  {P}  (7) 

The  familiar  Hoare  [7]  assignment  rule  applies: 
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Rule  of  Consequence: 

P'=>P,  {P}PO(S){Q},  Q^Q' 

{P1}  PO(S)  {Q'} 

Rule  of  Equivalence: 

PO(S),  Ipo(s)  =  Ipo'(S),  pr e(PO'(S))  A  at(S)  =>  pre(  PO(S)) 

PO'(S)  {> 

Rigid  Variable  Rule:  R0(5)£xp  denotes  a  proof  outline  in  which  rigid  variable  X  in  every 
assertion  is  replaced  by  Exp,  an  expression  involving  constants  and  rigid  variables 
(only). 

{P}  PO(S)  {<?} 

{cM  TO(5)iP 

Conjunction  Rule:  P0a{S)(Q)P0b{S )  denotes  the  proof  outline  that  associates  assertion 
ACpABcp  with  each  control  predicate  cp ,  where  Xcp  is  the  assertion  that  POx(S) 
associates  with  control  predicate  cp. 

POa(S ),  POb(S) 

POa(S)  <2>  POb(S) 

Disjunction  Rule:  PO a{S)Q)  PO b(S)  denotes  the  proof  outline  that  associates  Acp  V  Bcp 
with  each  control  predicate  cp. 

POa(S),  POb(S) 

POa(S)  ©  POb(S)  i  j 


Figure  5:  Command-Independent  Rules  of  Ordinary  Proof  Outline  Logic 


Assignment  Axiom:  For  a  primitive  assertion  P:  {.P*}  x  e  {P}  (8) 

Sequential  composition  of  commands  is  like  Hoare’s  rule  without  deletion  of  the  intermediate 
assertion: 


Command  Composition  Rule: 

{P}  Si  {Ql,  {Q}  S2  {R} 

{P\Bl{Q}S2{R}  {  ’ 

In  order  to  reason  about  an  if  command,  we  must  reason  about  its  guard  evaluation  action  as 
well  as  the  commands  it  guards.  The  following  axiom  allows  us  to  derive  proof  outlines  for  guard 
evaluation  actions. 
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GEval;f(5)  Axiom:  For  an  if  command 

S-.iftfj-Sj  ••• 
and  a  primitive  assertion  P , 

{P}  GEvalif (5)  {P  A  (f\,at(S\)  =>  Bt)}  UO) 

A  proof  outline  for  an  if  is  then  constructed  by  combining  a  proof  outline  for  its  guard  evaluation 
action  with  a  proof  outline  for  each  alternative. 

if  rule: 

(а)  {/>}  GEvaljf(S)  {/?} 

(б)  (R  A  at(Si))  =>  Pi,  -  (#  A  at(Sn))  =>  Pn 

(c)  {Pi}  PO(Si)  {Q},  {Pn}  POjSni  {Q} 

{P} 

S:  ifBi-{Pi}PO(Si){Q}  (ID 

I- 

lBn-{Pn)PO(Sn){Q} 

fi 

{Q} 

The  guard  evaluation  action  for  do  selects  a  command  5,  for  which  corresponding  guard  B, 
holds.  If  no  guard  is  true,  then  the  control  point  following  the  do  becomes  active. 


GEvaldo(-S’)  Axiom:  For  a  do  command 

S:  do  Bi-*Si  |  •••  0  Bn-rSn  od 
and  a  primitive  assertion  P, 

{P}  GEvaldo(5)  {PA(A,-<»i(S;)  =>  B,)  A  (after(S)  =>  (-2?,  A---A-Bn))}  (12) 


The  inference  rule  for  do  is  based  on  a  loop  invariant ,  an  assertion  I  that  holds  before  and  after 
every  iteration  of  a  loop  and,  therefore,  is  guaranteed  to  hold  when  do  terminates — no  matter  how 
many  iterations  occur. 

do  rule: 

(a)  {/}  GEvaldo(S)  {R} 

( b )  (R  A  at(Si))  =►  Pi,  (R  A  at(Sn))  =>  Pn 

(C)  {Pi}  PO(Sl)  {/},  {Pn}  PO(Sr,)  {/} 

( d )  (R  A  after(S))  =>  (I  A  -*B\  A  ■  ■  ■  ’  ; _ 


5:  do  Bx-{Pi}PO{Si){l} 
!••• 

\Bn-*{Pn}PO(Sn)\l} 

od 

{I  A  ~'B]  A  ■■■  A  -'Bn} 
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The  inference  rule  for  a  cobegin  combines  proof  .  ut Lines  for  its  component  processes  An 
interference-freedom  test  [12]  ensures  that  execution  of  an  atomic  action  in  one  process  'Hes  not 
invalidate  the  proof  outline  invariant  for  another.  This  interference- freedom  test  is  formulated  in 
terms  of  triples, 

XI ( o ,  A ) :  { pre( a)  A  A }  o  { A } 

that  are  valid  if  and  only  if  o  does  not  invalidate  assertion  A.  If  no  assertion  in  PC) >  5,  is  invalidated 
by  an  atomic  action  a  then,  by  definition,  I po(S,  ;dso  cannot  be  invalidated  by  a.  Therefore,  we  can 
prove  that  a  collection  of  proof  outlines  PO(S  t ).  ....  PO{Sn)  are  interference  fret  by  establishing: 

Interference  Freedom  (Hi 

For  all  i,  j,  1  <  i  <  n,  1  <  j  <  n.  i  ^  j: 

For  all  atomic  actions  o  in  S,  : 

For  all  assertions  A  in  PO(Sj)  : 

XI [a,  .4)  is  valid. 

The  following  inference  rule  characterizes  when  a  valid  proof  outline  for  a  cobegin  will  result 
from  combining  valid  proof  outlines  for  its  component  processes: 

cobegin  rule: 

(a)  PO(Sl) .  PO(Sn) 

(b)  P=>  (Atpre(F<9(5,))) 

(c)  (A,  post {PO(Si)))*Q  (15) 

(tf)  PO(S\ PO(Sn)  are  interference  free 

{P}  cobegin  PO(Si)//  •  •  ■ // PO(Sn)  coend  (Q) 

Since  execution  of  an  atomic  action  a  in  one  process  never  interferes  with  a  control  predicate 
cp  in  another,  certain  interference- freedom  triples  follow  axiomatic  ally. 

Process  Independence  Axiom:  For  a  control  predicate  cp  in  one  process  end  a;i  atomic 
action  q  in  another, 

{cp  =  X}  a  {cp  -•  X}  ( 16) 

Notice  that  NI(a,cp )  follows  directly  from  this  axiom  when  a  and  cp  are  from  different  processes. 

2.4  From  Proof  Outlines  to  Safety  Properties 

Theorems  of  Proof  Outline  Logic  can  be  used  in  verifying  safety  properties  because  of  the  way  that 
proof  outline  validity  is  defined.  If  a  proof  outline  PO(S )  is  valid  then  Ipo(S)  must  he  an  invariant . 
Suppose  that  Ipo(s)  is  an  invariant.  Then  according  to  the  method  of  Section  1  for  proving  safety 
properties,  we  can  prove  that  executions  of  5  starting  with  prefFOtS))  true  will  satisfy  the  safety 
property  proscribing  -><?  by  proving  (at(S)  A  pre(  P0(5)))  =>  Ipp(s)  and  Ipo(S)  =*  "’<?•  The  proof 
of  (at(S)  A  preFO(S))  =>  Ipo(S)  follows  trivially  from  th-  .vay  f  po(S)  is  defined.  And.  to  prove 
Ipo{S)  ~'Qi  WG  simply  pwe 

(cp  A  Acp)  =>  Q  (171 

for  every  assertion  Acp  in  PO(S),  where  .4cp  is  the  assepim  that  PO(S)  associates  with  control 
predicate  cp.  For  example,  we  prove  as  follows  that  for  ■  i,e  absolute  value  program  in  Figure  2 
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after(S)  =>  (x  =  jX|)  holds  during  executions  started  in  a  state  satisfying  x  =  X  A  at{S):  For  tin- 
case  where  cp  does  not  imply  after(S),  (17)  is  trivially  valid.  The  remaining  cases  are  when  rp  is 
aftcr(S i),  after(S2)  and  after(S).  Here,  we  must  show 

after(S\ )  A  postf.Sy)  =>  (after(S)  =>  (x  =  |x|)) 

aftcr{ S-2 )  A  post( So)  =>  (after(S)  =>  (x  =  jx|)) 

after(S)  A  post( 5)  =>  (after(S)  =>  (x  =  jx|)) 

All  are  valid. 

3  Real-time  Logic 

3.1  A  View  of  Real  Time 

In  taking  into  account  real-time,  our  universe  of  discourse  comprises  processes  executing  parts  of 
some  program  along  with  an  external  world.  We  thus  are  forced  to  consider  three  kinds  of  actions: 

Ordinary  actions:  Atomic  actions  without  timing  constraints  are  called  ordinary  actions.  They 
may  execute  whenever  they  are  enabled,  or  wait  arbitrarily  long. 

Real-time  actions:  A  real-time  action  is  an  atomic  action  whose  execution  time  is  constrained. 

Idles:  Execution  time  may  pass  without  the  program  doing  anything.  Such  a  passage  of  time  can 
be  attributed  to  the  external  world,  and  we  model  this  by  an  i die. 

Ordinary  actions  are  familiar,  and  the  Proof  Outline  Logic  of  Section  2  works  fine  for  them. 
Real-time  actions  cause  no  logical  difficulties,  as  they  have  the  same  effects  on  variables  and  program 
state  as  ordinary  actions,  but  their  execution  is  more  constrained.  Adding  axioms  to  Proof  Outline 
Logic  suffices  for  reasoning  about  the  execution  time  of  real-time  actions.  Idles,  strangely  enough, 
are  more  troublesome  because  their  presence  causes  some  matters  of  logical  concern  (viz.,  the  time) 
to  change  without  program  execution.  For  example.  Rule  of  Consequence  (2)  is  unsound  when  idles 
are  present. 

In  defining  our  logic,  we  consider  an  extremely  powerful  real-time  language,  allowing  constructs 
that  may  be  impractical  or  impossible  to  implement.  Programmers  using  actual  languages  will 
not  necessarily  have  access  to  all  the  features  we  allow.  However,  we  believe  that  most  actual 
programs  in  our  intended  domain  can  be  translated  into  our  language.  Thus,  expressive  power  is 
an  advantage:  the  more  powerful  our  ’anguage.  the  greater  the  number  of  real  programs  that  can 
be  expressed  in  it. 

Our  programming  language  is  the  one  of  Section  2  wit h  additional  real-time  actions.  In  particu¬ 
lar,  for  each  unconditional  atomic  action4  a,  we  define  corresponding  real-time  action  (o)^  fj  where 
<5  and  e  are  real-valued,  non-negative  constants.  Execution  of  (q)[^,]  causes  the  same  indivisible 
state  transformation  as  a  does,  but  constrains  it  to  occur  at  some  instant  between  c  and  f  +  f<  time 
units  after  the  entry  control  point  for  becomes  active. 

We  have  elected  to  characterize  the  execution  time  for  a  real-time  action  in  terms  of  two  parame¬ 
ters  (6  and  e),  foilowing  [14],  in  order  to  gain  flexibility  in  modelling  various  execution  environments. 

*An  atomic  action  is  unconditional  if  it  is  executable  whenever  its  entry  control  point  becomes  active.  In  the 
programming  notation  of  Section  2,  skip,  assignment,  and  the  guard  evaluation  action  for  do  are  unconditional  The 
guard  evaluation  for  if  is  not  unconditional. 
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Parameter  f  describes  the  fixed  execution  time  of  the  action  on  a  bare  machine;  6  models  execu¬ 
tion  delays  attributable  to  multiprogramming  and  other  resource  contention.  A  system  where  each 
process  is  assigned  its  own  processor  is  modeled  by  choosing  0  for  6;  a  system  where  processors  are 
shared  is  modeled  by  choosing  a  value  for  6  based  on  the  length  of  time  that  a  runnable  process 
might  have  to  wait  for  a  processor  to  become  available. 

As  an  illustration,  suppose  we  know  that  assignment  commands  take  one  time-unit,  and  that 
there  is  a  single  processor.  If  three  assignment  commands  are  started  concurrently,  they  will  be 
executed  in  some  order.  The  first  one  to  run  will  be  started  immediately  and  take  one  time-unit; 
the  last  one  will  be  started  two  units  after  it  was  issued,  and  it  also  takes  one  time-unit.  Thus  we 
could  model  this  with  real-time  actions  having  an  execution  time  of  1  and  a  possible  delay  of  2. 

cobegin  (xl  :=  1)[21]//(x2  :=  2)[21j//(i3  :=  3)[2  ,j  coend 

We  do  not  allow  a  in  a  real-time  action  (a)^  to  be  a  conditional  atomic  action,  such  as  an 
if  guard  evaluation  action,  because  it  is  not  clear  what  such  a  construct  would  mean.  The  delay 
in  a  conditional  atomic  action  is  already  dependent  on  something  else  -  changes  to  the  program 
state.  Lower  bounds  on  conditional  atomic  actions  ( e.g .,  an  if  command  that  requires  at  least  one 
time-unit  to  evaluate  its  condition)  can  be  implemented  with  a  real-time  skip  command  followed  by 
an  ordinary  if.  Timeouts  on  conditional  atomic  actions  can  be  implemented  by  parallel  processes 
and  shared  variables. 

When  writing  a  real  time  program,  it  is  sometimes  necessary  to  program  a  loop  whose  iterations 
have  fixed  or  bounded  execution  time.  All  of  the  atomic  actions  in  such  a  loop  must  be  real-time 
actions.  We  therefore  introduce  the  following  syntax  to  specify  that  {GEvala„(5))^  ej  be  used  as 
the  guard  evaluation  action  in  a  do  command: 


({  ••  •  (J.0n-*5'„od 


(18) 


3.2  Reasoning  About  Real-time  Actions 

To  reason  about  timing  properties,  terms  are  added  to  the  assertion  language  and  additional  in¬ 
formation  is  included  in  the  program  state.  This  is  because  the  method  of  Section  2  for  reasoning 
about  safety  properties  can  only  be  used  to  prove  safety  properties  for  which  the  negation  of  the 
proscribed  -*Q  is  implied  by  each  of  a  proof  outline’s  assertions.  Timing  properties,  by  definition, 
concern  the  instants  at  which  control  predicates  become  active,  so  we  define  a  term  ]cp  for  each 
control  predicate  cp: 

.  \t  l  is  the  time  that  cp  last  became  true  , 

}cp  =  <  19 

1  — oo  cp  has  never  been  true 

We  also  define  a  new  real-valued  term  T  to  be  equal  to  the  current  time. 

Only  certain  assignments  of  values  to  these  terms  are  sensible  in  a  program  state.  In  particular, 
if  two  control  points  become  active  as  part  of  the  same  event,  then  they  must  be  assigned  the  same 
time.  For  example,  since  S  is  the  first  subcommand  of  5  T,  we  require  that  Intf-S")  =  ]af{S  T). 
Similarly,  the  subcommands  S i  and  S 2  in  5:  cobegin  S1//S2  coend  start  at  the  same  time,  so 
we  require  fat(Si)  =  fo<(52)  =  ]at(S). 

Notice  what  effect  adding  these  terms  to  the  state  has  on  the  definit  ion  of  proof  outline  validity. 
Recall  that  a  proof  outline  PO(S )  is  valid  if  execution  starting  in  any  state  that  satisfies  Ipo(S) 
leaves  lpo(S\  invariant.  Now,  a  state  includes  a  time,  and  so  we  must  consider  starting  states  with 
arbitrary  times  as  well  as  arbitrary  values  for  program  variables  and  control. 
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Let  <E[S]  be  a  program  containing  a  copy  of  S.  An  initial  state  of  C[S]  not  only  must  satisfy 
af(C[S]),  but  must  be  one  in  which  the  value  of  T  is  some  non-negative  number,  and  the  values 
of  fat(T)  and  | after(T)  (for  every  command  T)  are  initialized  properly.  That  is,  for  any  control 
predicate  cp ,  if  ni(C[5])=>  cp  is  valid,  then  fcp  has  the  same  value  as  T;  otherwise  it  is  -oc.  The 
elements  a  of  Jif  are  those  infinite  sequences  of  states  such  that: 

•  cr0  is  a  state  reached  by  executing  some  program  C[S]  zero  or  more  steps  from  an  initial  state, 
updating  T,  fat(T),  and  ]after{T)  appropriately  on  each  step. 

•  Each  state  cr1+i  is  the  result  of  performing  an  ordinary  action,  a  real-time  action,  or  an  idle 
from  (7 , .  Execution  of  an  ordinary  or  real-time  action  updates  T,  \at(T).  and  ]aftcr(T) 
appropriately.  Execution  of  an  idle  only  updates  T,  and  in  a  way  that  does  not  violate  the 
bounds  6  and  e  associated  with  any  enabled  real-time  action.  If  no  action  of  S  is  enabled, 
then  the  only  transition  permitted  is  an  idle  that  does  not  increase  T. 

Validity  of  proof  outlines  in  our  real-time  logic  is  defined  as  before  (Section  2.2).  using  in 
place  of  : 


Real-Time  Invariance: 


wj  N  Ipo(S)  =>  ®Ipo(S) 


(20) 


Real-Time  Self-Consistency:  (at(S)  A  pre(S))  =>■  Ipo(S) 


Axioms  and  Rules  for  Real  Time 

Execution  of  a  real-time  action  (a)^cj  affects  the  program  variables  and  control  predicates  in 
the  same  ways  as  the  ordinary  action  a  from  which  it  was  derived.  Therefore,  we  have  the  following 
inference  rule: 

Real-time  Action  Transformation:  For  a  an  unconditional  atomic  action.  P  and  Q 
primitive  assertions,  and  0  <  6  and  0  <  e: 


{P) « {<?} 
{P)  <«>(*,<] 


(21) 


Some  additional  axioms  and  inference  rule  allow  us  to  reason  about  formulas  of  our  more  ex¬ 
pressive  assertion  language.  First,  the  various  non-atomic  commands  of  our  programming  language 
give  rise  to  axioms  based  on  the  way  they  equate  their  components’  control  points.  These  axioms 
are  similar  to  the  control-predicate  axioms.  For  our  programming  language,  these  axioms  are  given 
in  Figure  6. 

Next,  there  are  the  additional  axioms  given  in  Figure  7  for  the  assertion  language.  In  these,  cp 
can  denote  any  control  predicate,  including  those  not  associated  wr  h  entry  or  exit  control  points  for 
real-time  actions;  S  is  the  label  for  a  real-time  action  (q)^.  Axioms  (22)  and  (23)  follow  directly 
from  the  definition  of  ]cp.  Axioms  (24)  and  (25)  capture  the  essence  of  a  real-time  action— that 
its  entry  control  point  cannot  stay  active  too  long.  This,  in  :urn.  allows  us  to  infer  that  a  control 
point  is  not  active  by  using  the  following  corollary  of  (24): 


(|a/(5)  +  <5  +  c  <  T)  =>  -itii(S) 


(2(5) 
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For  5  the  sequential  composition  SiS2 

ja<(5) 

= 

f«*(Si) 

]after{S) 

= 

]after)S7) 

1  after  (Si) 

= 

]at)S2) 

For  an  if  command: 

S: 

if  Bi 

-S,B  •••  0An-5nfi 

T  at(S) 

= 

j«/(GEvalif(5')) 

j  after(S) 

= 

max  ( \after)Si),  ...  ,  j  after)  Sn)) 

j  a/ter(GEval;f(5)) 

— 

max(fnf(5i) . ]at)Sn)) 

For  a  do  command: 

S: 

do  B\ 

—‘Si  fl  ■  •  ■  i  Bn—Sn  od 

jafjGEvaWS)) 

= 

max  (fat  (5),  ]after)Si ), - fa//er(S„)) 

j  after)  G  E  vald0(  S ) ) 

= 

max(  ]after)S),  \at)Si) . T«/(5„)) 

-<in)S) 

=> 

I  af(er)S)  =  ja/ter(GEvaldo(5)) 

at(S) 

jat(S)  =  jaf(GEvaldo(5)) 

in(Si) 

=> 

jat(5,)=  fa/fer(GEvalj0(5)) 

after)  S) 

=> 

j  after) Si)  =  ja/(GEvaldo(S)) 

For  a  cobegin  command: 

5: 

cobegin  Si//  ■  •  ■  //  Sn  coend 

]at)S) 

= 

ja<(5,)  =  |af(S2)  =  •  •  •  =  ]at)Sn) 

j  after)  S) 

St 

max(  ]after(Si) . )after)Sn)) 

Figure  6:  Control  Time  Axioms 


The  way  these  new  terms  change  value  when  atomic  actions  execute  is  captured  by  new  axioms. 
For  any  ordinary  or  real-time  atomic  action  a  and  control  predicate  cp,  we  have: 

cp  Invariance  { cp  =  C  A  | cp  =  V}  a  {(cp=>  C)  =>  (jcp  =  V)}  (27) 

The  antecedent  in  the  postcondition  is  necessary  for  the  case  where  cp  could  become  true  when  o 
finishes,  e.g.,  cp  =  after(a). 

Next,  for  any  ordinary  action,  we  have: 

Action  Time  Axioms: 

{K  <  T at(S)}  S:  a  {K  <  | after(S)}  (28) 

{K  <  T)  S:  a  { K  <  T aftcr(S)}  (29) 

Action  Time  Axiom  (28)  asserts  that  the  exit  control  point  for  S  becomes  active  after  the  entry- 
control  point  for  5  last  became  active.  Action-time  Axiom  (29)  makes  the  subtly  different  assertion 


Tcp  <  T  (22) 

(jcp  =  — oo)  =>  ->cp  (23) 

at(S)  =>  }at(S)<T  <1at(S)  +  fi  +  i  (2-1) 

jat(S)  ^ -oo  =>  ]after(S)  <  ]at’ 1  6  +  f  (25) 


Figure  7:  General  Real-Time  Axioms 
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that  the  exit  control  point  for  5  becomes  active  after  every  time  that  the  entry  control  point  for  S 
was  active. 

For  a  real-time  action  (a)j£  fj,  the  following  axiom  characterizes  how  execution  changes  the 
\  cp-terms. 

Real-time  Action  Axiom  {K  <  T<d(S)}  S  :  (o)|^{j  {K  +  <  <  ]af(er(S)}  (30) 

This  axiom  is  analogous  to  Action-time  Axiom  (28),  except  that  now  the  postcondition  has  been 
strengthened  to  give  a  tighter  lower-bound  on  when  the  exit  control  point  for  5  first  becomes  active. 

Two  things  that  the  Real-time  Action  Axiom  (30)  does  not  say  are  worthy  of  note.  First,  this 
axiom  does  not  bound  the  interval  during  which  the  entry  control  point  for  S  is  active;  Axiom  (24) 
serves  that  role.  Second,  one  might  expect  the  following  triple  to  be  valid— its  precondition  being 
similar  to  that  of  (29). 


{K  <  T}  5:  (a)M  {K  +  e  <  T}  (invalid)  (31 ) 

Unfortunately,  (31)  is  not  sound.  Execution  of  5  started  in  a  state  such  that  ja/(a)  <  K  <  T  would 
satisfy  the  precondition  but  might  terminate  before  K  +  (.  For  example,  consider  an  execution  of 
(a)j02]  that  is  started  at  time  0.  Thus,  at  time  T  —  1  the  state  satisfies  K  <  T  if  we  choose  K  =  1. 
and  so  precondition  K  <  T  is  satisfied  by  that  state.  When  execution  of  (a)[0  2j  terminates — 2 
units  after  it  is  started — at  time  T  =  2,  the  postcondition  K  +  c  <  T  is  1  +  2  <  2,  which  is  false. 

Finally,  the  following  rule  allows  rigid  variables  to  be  instantiated  with  expressions  involving 
|cp-terms.  (Rigid  Variable  Rule  (4)  only  allows  rigid  variables  to  be  instantiated  by  constants, 
rigid  variables,  or  expressions  constructed  from  these.) 


Tcp-Instantiation 


{|cp=  V}  o  {|cp  =  V},  {P}  a  {Q} 

~  .(«u 


(32) 


This  rule  is  typically  used  along  with  cp  Invariance  (27).  For  the  case  where  real-time  action 
a  and  control  predicate  cp  are  in  different  processes,  the  first  hypothesis  of  jcp-Instantiation  is 
automatically  satisfied  due  to  Process  Independence  Axioms  (16).  Thus,  we  obtain  a  derived  rule 
of  inference: 


q  and  cp  are  in  different  processes, 


Derived  Tcp-Instantiation 

{P}q( 

[Q) 

1 

fpxH 

iMcpj 

\  Q  \ 

]ox  1 

(33) 


3.3  Rule  of  Consequence  Revisited 

Most  of  the  axioms  and  proof  rules  of  Proof  Outline  Logic  are  sound  in  our  real-time  setting. 
However,  the  Rule  of  Consequence  (2)  is  unsound  and  needs  revision.  We  also  need  to  revise 
the  notion  of  interference  freedom.  While  the  Owicki-Gries  cobegin  rule  [12]  is  sound,  when  the 
assertion  language  concerns  real  time,  the  rule  is  is  no  longer  complete  and,  in  particular,  not 
powerful  enough  for  even  simple  examples  of  concurrent  real-time  programs. 

Rule  of  Consequence  (2)  is  invalid  in  any  setting  where  some  aspect  of  the  state  is  not  under 
program  control.  Recall,  the  rule  is: 
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Maxldle(a) 

MaxIdle((a)M) 

Maxldle(5,52) 

Maxldle(if  •  ■  -  fi) 

MaxIdle(do  •  •  -  od) 

MaxIdle(do[j  {]  •  •  -  od) 
MaxIdle(cobegin5t^  •  * -//5„coend) 


oo  a  ordinary 

5  +  ( 

Nlaxldl  e(St) 

oo 

cc 

6  +  ( 

min  {Maxldle(5,)|i  =  l,...,n} 


Figure  8:  Definition  of  MaxIdle(S),  the  maximum  idle  of  S 


P'=>P,  {P}PO(S){Q},  Q=>Q' 

{P'}  PO(S)  {Q1} 

The  difficulty  is  illustrated  by  the  following  example.  Consider  the  following  proof  outline,  which 
is  valid  in  our  model: 

{T  >  4}  S:  skip  {true}  (34) 

Furthermore,  note  that 

(T  =  4)  =>  (T  >  4)  (35) 

is  valid.  However,  if  we  apply  the  Rule  of  Consequence  to  (34)  and  (35),  we  obtain  the  following 
proof  outline: 

{T  =  4}  S:  skip  {true}  (36) 

It  is  invalid  because  an  idle  by  the  environment  invalidates  its  precondition,  T  =  4.  In  particular, 
let  7  be  a  state  in  which  at(S)  A  T  ~  4  is  true.  Therefore,  the  precondition  of  (36)  is  satisfied  by 
7,  and  so  is  Ipo(S)-  An  idle  can  lead  to  a  state  7'  in  which  at(S)  AT  =  4.01,  invalidating  Ipo(S)- 
Thus  the  proof  outline  does  not  satisfy  Real-Time  Invariance  (20),  and  hence  is  not  valid. 

We  eliminate  problems  of  this  sort  by  modifying  Rule  of  Consequence  (2)  so  that  idles  cannot 
invalidate  a  strengthened  precondition  P' .  In  light  of  (36),  an  obvious  approach  is  to  rule  out  any 
strengthening  of  preconditions  achieved  by  placing  an  upper  bound  on  T.  However,  that  restriction 
would  prevent  us  from  deriving  the  valid  triple 

{|at(S)  =  4A4<T<6}5:  skip[02j  {true}.  (37) 

We  therefore  characterize  the  interval  over  which  a  strengthened  precondition  P'  must  not  be 
invalidated  by  an  idle.  For  any  program  5,  define  Maxldlei  (maximum  idle  time  for  5)  to  be  the 
longest  real  time  interval  that  can  elapse  after  at(S )  become1-  true  but  before  some  program  action 
of  5  must  be  executed.  If  5  may  idle  arbitrarily  long,  then  Maxldle(5)  =  00.  Figure  8  gives  a  way 
to  calculate  MaxIdle(S)  by  induction  on  the  structure  of  5. 

For  example, 

Maxldle(skip)  =  00 
as  skip  can  wait  arbitrarily  long  before  taking  a  step,  and 

MaxIdle(cobegin  skip^(skip)[0  2  coend)  =  2 
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as  that  program  will  necessarily  take  a  step  at  or  before  time  2.  In  order  for  Rule  of  Consequence 
(2)  to  be  sound,  not  only  must  P'=>P  hold  but  P'  must  remain  true  until  time  I«t(5)  +  Maxldle(5}. 
We  say  that  an  assertion  P  is  patient  for  5  if 

(PAai(5))^  (yd.(T  <  d  <  ]at{S)  +  MaxIdle(S))  =>  Pj)  (38) 

Thus,  if  P'  is  patient  for  5,  then  P'  can  be  a  precondition  for  S  and  no  idle  by  5  can  invalidate 
P' .  For  example,  4  <  T  <  6  is  patient  for  (skip)j0  2j,  but  4  <  T  <  5  is  not.  A  corollary  of  the  way 
TfJ  is  constructed  is  that  the  precondition  of  any  valid  proof  outline  PO(S)  is  patient  for  5. 

Note  that  under  some  circumstances  P'  is  easily  demonstrated  to  be  patient  for  S: 

•  If  P'  does  not  mention  T. 

•  If  P'  only  gives  lower  bounds  on  T. 

However,  even  assertions  involving  upper  bounds  on  T  can  be  patient.  For  example. 

I at{S)  =  4  A  4  <  T  <  6 

is  patient  for  5  :  skipf0  2p 

A  sound  Rule  of  Consequence  for  our  real-time  logic  can  be  formulated  in  terms  of  patient 
assertions: 


Rule  of  Consequence: 

P'  =4-  P,  P'  is  patient  for  S ,  {/>}  PO(S )  {<?},  Q  ^  Q' 

{P'}  po{S)  {g'} 


(39) 


So,  because  T  =  4  is  not  patient  for  skip,  it  is  not  possible  to  deduce  (36)  from  (34)  and  (35) 
using  this  new  Rule  of  Consequence.  On  the  other  hand,  because 


fto<(5)  =  4  A  4<T<6)=>T>4 


(40) 


is  valid  and  fai(5)  =  4A4<T<6is  patient  for  skip[02],  we  can  use  the  Rule  of  Consequence 
(39)  to  infer 

{fa£(5)  =  4  A  4<T<6}  skipj02j  {true}  (41) 

Note  that  we  do  not  need  to  place  similar  restrictions  on  Q' .  The  interpretation  of  {  P}  PO(S)  {Q } 
is  that,  when  5  finishes,  Q  remains  true  indefinitely.  If  Q  =>  Q'  in  predicate  logic,  and  Q  remains 
true  forever,  then  Q'  will  also  remain  true  forever. 

The  following  derived  rule,  the  Simple  Rule  of  Consequence,  handles  most  of  the  bookkeeping 
uses  of  the  Rule  of  Consequence  (39): 


Simple  Rule  of  Consequence 


P'  =  P,  {P}  PO(S )  (Q),  Q  =>  Q' 
{P'\  PO(S)  {Q'} 


(42) 
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3.4  Interference  Freedom  Revisited 

When  execution  times  of  atomic  actions  are  bounded,  certain  forms  of  interference  cannot  occur. 
This  is  illustrated  by  the  following  proof  outline. 


{x  =  0} 

cobegin 

{x  =  0}  a:  (x  :=  x  +  1)[0  2]  {x  =  1} 

// 

{x  =  0}  0:  (y  :=  x  +  l)[0il]  {y  =  1} 

coend 

{x  =  1  A  y  =  1} 


It  is  valid,  but  cannot  be  derived  using  the  cobegin  Rule  because  PO{a)  and  PO(0)  are  not 
interference  free.  In  particular,  NI(a,  pre(0))  is  not  valid. 


NI(a, pre(0)) 

=  {pre(a)  A  pre(/3)}  <x  :=  x  +  1)[02]  {pre(/?)} 

=  {x  =  0}  (x  :=  x  4-  1)[02)  {x  =  0} 

Using  operational  reasoning,  however,  it  is  not  difficult  to  see  that  executing  a  cannot  invalidate 
pre(/3),  so  PO(a)  and  PO(0)  should  be  considered  interference  free.  This  is  because  according  to 
Figure  6,  both  at(a)  and  at{0)  become  active  at  the  same  instant,  say  time  0.  By  definition,  a 
completes  at  time  2,  and  so  x  remains  0  until  this  time.  Real-time  action  0  completes  at  time  1 
and,  therefore,  must  find  x  to  be  0.  Thus,  it  is  simply  not  possible  or  a  to  change  the  value  of  x 
while  at(0 )  is  active. 

The  ordinary  cobegin  Rule  (15)  is  based  on  a  form  of  interference  freedom  that  does  not  take 
into  account  execution-time  bounds  of  real-time  actions.  In  particular,  A7(a,  ACJ> )  does  not  account 
for  the  fact  that  although  Acp  might  be  associated  with  an  active  control  point  cp  when  a  is  started 
then  we  may  be  able  to  prove  that  cp  cannot  be  active  when  a  completes.  The  remedy  is  to  refine 
NI(a,  Acp)  taking  into  account  the  time  bounds  for  how  long  an  entry  control  point  for  a  real-time 
action  can  remain  active.  The  following  triple  accomplishes  this.5 

NIr t(a,Acp):  (a<(a)  A  pre(a)  A  cp  A  Acp}  a  {cp=>  Acp) 

Returning  to  the  example  above,  we  now  have: 


A7r*(a,pre(/3)) 

=  {at(a)  A  pre(a)  A  at(0)  A  pre(/?)}  (x:=x  +  l)j0  2j  {at(0)  =>  pre(0)} 

=  {af(a)  A  at(0)  A  x  =  0}  (a:  :=  x  +  l)[0-2]  iat(0)  1  —  0} 

And.  this  obligation  can  be  discharged  as  follows.  We  present  the  proof  in  detail,  to  show  how 
the  axioms  and  rules  fit  together.  Steps  that  involve  standard  logic  (including  arithmetic)  are  listed 
as  simply  “predicate  logic.” 

^TliLs  triple  is  not  specific  to  real  time;  see  [11]  for  example.  It  ari-  s  naturally  when  one  attempts  to  construct  a 
proof  rule  for  cobegin.  In  many  cases,  it  can  be  simplified  to  the  Owicki-Gries  condition,  but  here  it  cannot 
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1.  Real-time  Action  Axiom  (30) 

{K  <  Ta<(a)}  a  :  (x  :=  x  +  l)f02j  {K  +  2  <  ]after(a)} 

2.  Derived  fcp-lnstantiation  (33)  with  1,  substituting  jat(i3)  for  K 
{fa/(/3)  <  fat(a))  a:  (i  :=  z  +  1)[0<2,  {]at{0)  +  2  <  }after(a)} 

3.  Axiom  (22)  with  f after(a)  for  f cp,  and  predicate  logic 
(T at(0)  +  2  <  | after(a))  =>  (f at(fl)  +  2  <  T) 


4.  Simple  Rule  of  Consequence,  (42)  with  2  and  3 

{]at(P)  <  |a<(a)}  <*:  <i  :=  x  +  1)[0,2]  (1at(0)  +  2  ^  T) 

5.  Axiom  (24)  and  predicate  logic 

at(0)  =>  T at((3)  <  T  <  t at(0)  +  1 


6.  Predicate  logic  and  arithmetic: 

(at(0)  =>  T  at(p)  <T<  T  at(0)  +  1)  =►  ((}at(0)  +  2  <  T)  =>  -<at(0)) 


7.  Modus  Ponens  from  5  and  6 

(fat(j3)  +  2  <  T)=>->at(0) 


8.  Simple  Rule  of  Consequence  with  4  and  7 

itat(fi)  <  Jat(a)}  a:  (x  :=  x  +  1)|0)2]  {-.a<(0)} 

9.  A  Control  Time  Axiom  from  Figure  6 

}at(a)  =  }at(P) 


10.  Predicate  logic  from  9 

<  fat(a) 


11.  Predicate  logic  from  10,  since  anything  implies  true 

pre(JV/rt(a,pre(/3)))  =>  |at(/9)  <  tat(a) 


12.  Predicate  logic 

->at(P)  =>  post(NIrt(a,  pre(/3))) 

13.  Rule  of  Consequence  with  8,  11,  and  12;  patience  is  vacuous 
A7r((a,pre(/J)) 
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Notice  that  information  about  the  time  after  a  is  accumulated  in  steps  4  and  5.  and  used  in 
step  6  to  reach  the  same  conclusion  that  operational  reasoning  gave:  that,  once  a  finishes,  fi  has 
also  finished. 

4  Example:  A  Mutual  Exclusion  Protocol 

cobegin 

6  :  if  :r  =  0  —  c:  (x  :=  l)[4(cMe)]fi 
d  :  (skip)^)  ((rf)) 

e  :  if  x  =  1  — ►  /:  Critical  Section  fi 

// 

b'  :  if  z  =  0  -  c':  ( x  :=  2>[6(c,}  ((c,}]  fi 
d!  :  <skip)j5(J,) 

e'  :  if  x  =  2  — *  /':  Critical  Section  fi 

coend 


Figure  9:  Core  of  Fischer’s  Mutex  Protocol 

Knowledge  of  execution  times  can  be  exploited  to  synchronize  processes.  A  mutual  exclusion 
protocol  attributed  in  [10]  to  Mike  Fischer  [4]  illustrates  this  point.  The  core  of  this  protocol 
appears  in  Figure  9.  There,  c,  d,  c'  and  d'  are  real-time  actions.  Provided  the  parameters  defining 
these  real-time  actions  satisfy 


S(c')  +  e(c')  <  c(d) 

(43) 

6(c)  -1-  e(c)  <  e(d') 

(44) 

this  protocol  implements  mutual  exclusion  of  the  marked  critical  sections,  as  we  now  show. 

Mutual  exclusion  of  at(f)  and  at{f )  is  a  safety  property.  It  can  be  proved  by  constructing  a 
valid  proof  outline  in  which  pre(/)  =>  -> at(f )  and  pre(/')  =>  A  standard  approach  for  this 

is  to  construct  a  valid  proof  outline  in  which  -~'(p re(/)  A  pre(/'))  is  valid.  It  is  thus  impossible  for 
at(f)  A  at(f')  to  hold,  because  that  would  imply  pr e(/)  A  pre(/'). 

A  proof  outline  for  the  first  process  is  given  in  Figure  10;  the  proof  outline  for  the  other  process  is 
symmetric,  with  “1”  everywhere  replaced  by  “2”  and  the  primed  labels  interchanged  with  unprimed 
ones.  Notice  that  pre(/)=>i  =  1  and  pr  e(/')=>x  =  2.  Thus,  the  proof  outlines  satisfy  the  conditions 
just  outlined  for  ensuring  that  states  satisfying  at(f)  A  at(f)  cannot  occur. 

It  is  not  difficult  to  derive  the  proof  outline  of  Figure  10  using  the  axiomatization  of  real¬ 
time  actions  given  above.  The  proofs  of  {pre(c)}  c  {post(c)}  and  {pre(d)}  d  {post(d)}  are  the 
most  enlightening,  as  they  expose  the  role  of  assumptions  (43)  and  (44)  in  the  correctness  of  the 
protocol.  Here  is  the  proof  of  {pre(c)}  c  (post(c)}: 

Let 

M  =  S(c')  +  c(c')  -  e(d) 


1.  Axiom  (29) 

{K  <  T}  c:  (*  :=  l)[4(cMc)]  {K  <  T after(c)} 
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{true} 

b:  ifx  =  0  — ►  {|a<(c')  <  T} 

c '  (X  :=  l)[«(c)rf(c)] 

{z  ^  0  A  ( at{c ')  =>  lat(c')  +  M  <  ]at(d)) } 

fl 


{i  /  0  A  (a*(c')  =>  T ot(c')  +  M  <  ta*(d)) } 
d:  (skip)jfi((i)j<{(fj] 

{i  ^  0  A  -iaf(c')} 

e:  if  x  =  1  —  {x  =  1  A  ->at(c')} 

/:  Critical  Section  1 
{true} 


{true} 


Figure  10:  Proof  Outline  for  Fischer’s  Algorithm 

2.  Derived  |q>-lnstantiation,  (33),  on  step  1,  to  substitute  fat(c')  for  K 
{Taf(c')  <  T)  c:  (x  :=  %(c),£(c)]  {ta<(c')  <  ta/fer(c)j 

3.  Control  Time  Axiom  (Figure  6)  for  if  and  sequencing 
]  after  (c)  ~  f at(d) 


4.  Predicate  logic  on  step  3,  and  M  <  0  by  (43) 

(f at(c')  <  1  after (c))  =>  (Tat(c')  +  M  <  fat(d)) 


5.  Predicate  logic  on  step  4 

jat(c')  <  | after(c)  =>  (at(c')  =>  (fat(c')  +  M  <  Ta<(d))) 

6.  Simple  Rule  of  Consequence  (39)  on  steps  2  and  5 

{Tat(c')  <  T}  c:  (*  :=  l)[5(c),e(c)]  {«<(c')  =>  (tat(c')  +  M  <  tat(<*))} 

7.  Assignment  Axiom  (8) 

{1  =  1}  c:  {x  :=  l)[6(e)if(c)]  {x  =  1} 


8.  Predicate  logic 

true  =>  (1  =  1) 


9.  Predicate  logic 
x  =  1  =>  x  ^  0 
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10.  Rule  of  Consequence,  (39)  on  steps  7,  8,  and  9,  since  true  is  patient  for  r. 

{true}  c:  (x  :=  %(c)i£(c)]  {*  #  0} 

11.  Conjunction  Rule  (5)  on  steps  10  and  6,  plus  a  trivial  use  of  the  Rule  of  Equivalence  (3). 
{faf(c')  <  T\  c:  (x  :=  %(c)e(c)]  {^0A  (at(c')  =>  I  at(c')  4-  M  <  ]at(d))} 

And.  here  is  the  proof  of  {pre(d)}  d  {post(<i)}. 

1.  Real-time  Action  Axiom  (30) 

{K  <  Taf(d)}  d:  <skip)[i(d)  t(d)]  {K  +  e(d)  <  t after(d)} 

2.  skip  Axiom  (7) 

{L  <  K}  d:  (skip)[i(d)e{rf)1  {L  <  K} 

3.  Conjunction  rule  (5)  on  steps  1  and  2 

{L  <  K  A  K  <  T aHd)}  d:  {skip}{5((/)  t(d)]  {L  <  K  A  K  +  ((d)  <  f  after(d)} 

4.  Predicate  logic 

(L  <  K  A  (K  +  ((d)  <  t after(d)))  =>  (L  +  c(d)  <  | after(d)) 

5.  Rule  of  Consequence  (39)  on  3  and  4,  noting  that  the  precondition  does  not  mention  time  and  is 
thus  patient. 

{L  <  K  <  t <>*(<*)}  d:  <skip)[tf(<0it(rf)]  {L  4-  ((d)  <  ]after(d)} 

6.  cp  Invariance  axiom,  (27) 

{at(d)  =  C  A  |af(d)  =  V}  d:  {skip)(i(d)>£(<i)]  {(at(d)  =>  C)  =>  (taf(rf)  =  V)} 

7.  Rigid  Variable  Rule  (4)  on  6,  replacing  C  by  true 

{at(d)  =  true  A  ]c  '(d)  =  V}  d:  (skip)Wrf)tt(rf)J  {(at(d)  =>  true)  *>(]at(d)  =  V)} 

8.  Rule  of  Equivalence  (3)  on  7 

{]at(d)  -  V}  d:  (skip)[i((i)  t(d)]  {t at(d)  =  V} 

9.  fcp-lnstantiation  (32)  using  8  and  5  to  substitute  | at(d)  for  I\. 

{L  <  ]at(d)  <  t at(d)}  d:  (skip)[5(rf)|t(d)j  {L  +  ((d)  <  ] after(d)} 

10.  Rule  of  Equivalence  (3)  on  9 

{L  <  ]at(d))  d:  <skip}[{((i)  £(rf)]  {L  +  ((d)  <  t after (d)} 
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11.  Derived  fcp-lnstantiation  (33),  and  Rigid  Variable  Rule  (4),  to  substitute  ]af(c')  +  M  for  L  in  10 

{taf(c')  +  M  <  T at{d)}  d:  (skip)|5(d)>{((f)]  [fat(c')  +  M  +  ((d)  <  j aftcrid )} 

12.  Process  Independence  Axiom  (16),  Rigid  Variable  Rule  (4),  and  Rule  of  Equivalence  (3) 
f-a<(c')}  d:  (skip)[S{d)  t(d)]  {-at(c')} 

13.  Disjunction  rule  (6)  on  steps  11  and  12 

{ -<at(c')  V  (f at(c')  +  M  <  f<V(cO)}  d:  {skip)[4((i)i((£i)j  {->a/(c')V  (]at(c')  +  M  T  ((d)  <  (aftcrid 

14.  Rule  of  Equivalence  (3)  on  13 

{at(c')=>  (|at(c')  +  M  <  ?<V(^))}  d:  (skip)^  {-’«/(c,)V  (\at(c')  +  M  +  e(d)  <  j  afttrid, 

15.  Axiom  (22) 

]after(d)  <  T 

16. 

-iaf(c')  V  T at(c')  4-  c(c')  +  S(c')  <  J after(d) 

=>  Predicate  Logic  from  step  15 
-af(c')  V  (M(c')  +  e(c')  +  6(c')  <  T) 

=>  Equation  (26) 

-iat(c')  V  ->at(c') 

=>  Predicate  Logic 
-i  at(c') 

17.  Simple  Rule  of  Consequence  (42)  on  steps  14  and  16 

{af(c')  =*►  (Tat(c')  +  M  <  ta<(d))}  d:  (skip)[5(d)  t(<f)]  {-af(c')} 

18.  skip  Axiom  (7) 

{x  #  0}  d\  (skip)[5(d)  c((i)]  {x  #  0} 

19.  Conjunction  Rule  (5)  on  steps  18  and  17 

{x  #  0  A  (af(c')  =»  (Taf(c')  +  M  <  taf(d)))}  d :  (sk\p}[8{d)({d)]  {i/OA  -’af(c')} 

Notice  how  timing  information  is  used  in  step  16  to  infer  that  a  particular  control  point  cannot 
be  active. 

5  Related  Work 

It  is  instructive  to  compare  our  logic  with  that  of  [17],  another  Iloare-stvle  logic  [7]  for  reasoning 
about  execution  of  real-time  programs.  In  [17],  the  passage  of  time  is  modeled  by  augmenting  each 
atomic  action  with  an  assignment  to  an  interval-valued  variable  RT ,  so  that  RT  contains  lower  and 


23 


upper  hounds  for  the  program's  elapsed  execution  time.  The  equivalent  of  our  Command  Composi¬ 
tion  Rule  (9)  and  the  Assignment  Axiom  (8}  would  then  be  used  to  derive  rules  for  reasoning  about 
these  augmented  atomic  actions.6  In  contrast,  our  logic  is  obtained  by  augmenting  the  assertion 
language  (of  an  underlying  logic  of  proof  outlines)  with  additional  terms  ( f  rp  and  T )  and  devising 
new  axioms  for  reasoning  about  these  terms.  We  cannot  derive  rules  for  real-time  actions  simply 
by  using  the  original  logic,  because  we  do  not  employ  assignment  commands  to  model  the  passage 
of  time. 

Although  our  logic  is  more  complex,  by  augmenting  the  axioms  rather  than  the  atomic  actions 
we  are  led  to  a  more  powerful  logic.  First,  having  the  f cp-terms  allows  the  logic  to  be  more  expres¬ 
sive.  These  terms  permit  the  definition  of  properties  involving  historical  information  --information 
that  is  not  part  of  the  current  state  of  the  program.  Timing  properties  that  constrain  the  elapsed 
time  between  events  can  only  be  formulated  in  terms  of  such  historical  information.  The  logic  of 
[17]  has  no  way  to  express  historical  information  and.  consequently,  can  be  employed  to  reason 
about  only  certain  timing  properties. 

Second,  our  axiomatization  allows  reasoning  about  programs  whose  timing  behavior  is  data- 
dependent.  The  logic  of  [17]  does  not  permit  such  reasoning.  For  example,  because  of  the  way 
command  composition  is  handled  in  [17],  tile  logic  produces  overly-conservative  intervals  for  time 
bounds.  This  is  illustrated  by  the  following  sequential  piogram.  which  takes  at  least  10  time  units 
to  execute. 

if\B  —  skip(0  9]  J  -> B  —  skipj0  jjfi 
if -'B  —  skip(0  9]  fl  B  —  skip[0  jjfi 

This  fact  can  be  proved  in  our  logic;  the  logic  of  [17]  can  prove  onlv  "h:A  execution  requires  at 
least  18  time  units. 

A  Hoare-style  programming  logic  for  reasoning  about  real-time  is  also  discussed  in  [8],  That 
work  is  incomparable  to  ours.  First,  the  programmin';  language  axiomatized  in  [8]  is  different, 
having  synchronous  message- passing  and  no  shared  variables.  This  is  symptomatic  of  a  fundamental 
difference  in  the  two  approaches.  The  emphasis  in  [8]  is  on  the  design  of  compositional  proof 
sy_  ems.  Shared  variables  could  not  be  handled  compositionally  and  so  they  are  excluded  from 
programs.  In  contrast,  we  do  not  require  that  our  proof  system  be  compositional,  and  we  do 
handle  shared  variables.7  Moreover,  it  would  not  be  difficult  to  extend  our  logic  for  reasoning  (non- 
compositionally)  about  programs  that  employ  synchronous  message-passing  or  any  of  the  other 
communication/synchronization  mechanisms  for  which  Hoare-style  axioms  have  been  proposed. 

The  set  of  properties  handled  in  [8]  is  also  incomparable  to  what  can  be  proved  using  our 
logic.  Our  timing  properties  make  visible  the  times  at  which  control  points  become  active  (through 
fcp-terms).  A  compositional  proof  system  cannot  include  information  about  control  points  in  its 
formulas,  because  they  betray  the  internal  structure  of  a  component.  The  logic  of  [8],  therefore,  may 
only  be  concerned  with  times  at  which  externally  visible  events  occur:  the  time  of  communications 
events  and  the  time  that  program  execution  starts  and  terminates.  This  turns  out  to  allow  proofs 
of  certain  liveness  properties  as  well  as  certain  safety  properties.  Our  logic  cannot  be  used  to  prove 
any  liveness  properties  other  than  those  implied  by  the  progress  of  time. 

^The  idea  of  augmenting  actions  with  assignment  commands  in  order  to  reason  about  the  passage  of  lime  is  also 
discussed  in  [5],  where  it  is  used  to  extend  Dijkstra’s  wp  [3]  for  reasoning  about  elapsed  execution  time  A  more 
recent  effort  to  augment  a  wp  call  ulus  for  real  time  is  reported  in  [16]. 

The  cobegin  Rule  of  Proof  Outline  Logic  (15)  is  not  compositional  because  its  interference-freedom  test  depends 
on  the  internal  structure  of  the  processes  being  composed. 
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A  concern  when  designing  a  logic  is  expressive  completeness.  On.  timing  properties  include  many, 
but  not  all.  safety  properties  of  interest  for  reasoning  about  the  behavior  of  real-time  programs. 
This  is  because  the  historical  information  in  a  timing  property  is  limited  to  times  that  control  points 
become  active.  One  might  also  be  concerned  with  the  elapsed  time  since  the  program  variables  last 
satisfied  a  given  predicate  or  with  satisfying  constraints  about  how  the  program  variables  change 
over  time.  These  are  safety  properties,  but  neither  is  a  timing  property  (according  to  our  definition  >. 
In  general,  safety  properties  can  be  partitioned  into  mvarianc t  properties  and  history  properlus 
[15].  The  invariant  used  in  proving  an  invariance  property  need  only  refer  to  the  current  state:  the 
invariant  used  in  proving  a  history  property  may  need  to  refer  to  the  sequence  of  states  up  to  the 
current  state.  Timing  properties  are  a  type  of  history  property. 

A  version  of  Proof  Outline  Logic  does  exist  for  reasoning  about  history  properties  [15].  It 
extends  ordinary  Proof  Outline  Logic  by  augmenting  the  assertion  language  with  a  "past  state" 
operator  and  a  function-definition  facility.  In  this  logic,  our  jcp-terms  can  be  constructed  explicitly: 
they  need  not  be  primitive.  And,  the  more  general  class  of  safety  properties  involving  times — be  it 
times  that  predicates  hold  or  times  that  control  predicates  hold — can  be  handled. 

A  Outline  of  the  Soundness  Proof 

A.l  Scheme  of  the  Proof 

Our  soundness  proof  has  a  straightforward  structure.  First  we  build  a  model,  using  structural 
operational  semantics  (SOS)  [13,  18,  6].  We  then  show  how  to  interpret  expressions  and  formulae 
of  the  logic  in  this  model.  Using  the  model,  we  define  the  set  of  execution  sequences  Hi  used  to 
define  validity  in  Section  3.2.  We  prove  a  series  of  “sanity  lemmas,”  showing  that  the  intuitive 
definitions  presented  earlier  match  the  formal  definitions.  Finally,  we  check  each  of  the  axioms  and 
proof  rules  against  the  model. 

The  most  subtle  part  of  the  construction  is  in  building  the  model.  Checking  the  axioms  and 
proof  rules  is  long  but  straightforward.  In  our  model,  we  give  a  structural  operational  semantics 
for  our  programming  language.  States  7  include  all  of  the  information  necessary  to  interpret  Proof 
Outline  Logic  assertions.  And,  the  operational  semantics  define  the  relation  7  <—  7',  stating  that  a 
program  in  state  7  can  perform  a  single  atomic  action,  or  can  idle,  and  enter  state  7'. 

Using  <-+,  we  construct  a  linear-time  temporal- logic  model  of  a  program  S;  that  is.  a  set  of 
infinite  sequences  T  of  states.  We  define  a  notion  of  “7  is  a  suitable  initial  state  for  S" .  We  get  an 
arbitrary  consistent  state  70  by  running  an  arbitrary  suitable  initial  state  7  for  5  arbitrarily  long. 
7  *  7o-  Hi  is  then  the  set  of  executions  of  S  started  in  arbitrary  consistent  states  70. 

Having  defined  Hi ,  we  have  have  enough  information  to  use  the  definition  of  Section  3.2  that 
[=  PO(S)  when  Hi  |=  Ipo(S)  =>  nIpo(S)-  This  puts  us  in  a  position  to  check  the  soundness  of  the 
logic,  which  is  tedious  but  not  difficult. 

A. 2  Defining  the  transition  relation 

Defining  relation  <— ►  is  nontrivial.  The  values  of  control  predicates,  especially  at  the  beginning 
and  end  of  concurrent  segments,  change  in  fairly  complicated  ways.  Consider  the  program  of 
Figure  11.  When  the  cobegin  labelled  a  finishes,  after(c)  or  aftcr(d)  will  hold  as  well  as  after(g) 
and  after(h)]  and  at(j ),  at(l),  and  at(m).  A  single  atomic  action  —  say,  <j  finishing  -  may  cause 
other  actions  at  faraway  points  in  the  program  to  start.  Or  it  mav  not. 
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a:  cobegin 
b:  if 

B i  — *  c :  skip 

I 

B2  —  d:  skip 
fi 

// 

e :  skip 
/:  cobegin 

9 :  skip 

// 

h :  skip 
coend 
coend 

i :  cobegin 

j :  skip 

// 

k:  cobegin 

l :  skip 

// 

m:  skip 
coend 
coend 


Figure  11:  Control  flow  example 

Any  description  of  the  state  transition  function  will,  at  some  level,  involve  an  inductive  analysis 
of  the  structure  of  the  original  program.  We  thus  chose  to  define  the  operational  semantics  of 
processes  directly,  using  SOS.  In  this  style,  the  behavior  of  a  composite  program  is  defined  in  terms 
of  the  behavior  of  its  subterms.  Since  the  state  7  must  contain  enough  information  to  interpret  all 
assertions  in  Proof  Outline  Logic,  it  must  include: 

•  at(l)  and  after(l)  for  each  label  l 

•  values  of  program  variables 

•  values  of  rigid  variables 

•  ta^(0  an<I  Ta/^er(0  for  each  label  / 

•  T 

All  save  the  first  can  be  encoded  directly  as  components  of  a  tuple.  For  example,  if  7  is  a  state, 
then  7.|at(-)  is  a  function  from  program  labels  to  times,  and  7 .cr( • )  is  a  function  from  program 
variables  to  values.  Following  the  usual  SOS  methodology,  program  counters  in  a  state  7  are 
represented  by  the  partiai  program  7 .5  that  remains  to  be  executed.  We  assume  that  programs  are 
completely  labelled;  that  is,  each  command  (simple  and  composite)  has  a  unique  label,  as  in  the 
example  above.  We  also  introduce  a  new  command,  done,  indicating  that  a  thread  of  computation 
has  finished. 
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We  now  define  the  relation  by  induction  on  7 .5.  By  in  large,  if  7  -  7',  then  7  and  7' 

are  almost  the  same;  e.g.,  most  variables  won’t  change  values.  We  therefore  present  the  SOS  rules 
by  explaining  the  differences  between  7  and  7'. 8  For  example,  if  7 .5  is  the  program  /  :  skip,  then 
the  operational  rule  which  applies  to  7  is: 

If 

7.5  =  l  :  skip 

7  '.S  =  l  :  done 

7  '.r  >  7.r 

7'  is  otherwise  the  same  as  7 
Then  7  <— *  7' 

The  behavior  of  a  composite  process  is  determined  inductively  by  the  behavior  of  its  subpro- 
cesses.  For  example,  cobegin  Si//  ■■■  //Sn  coend  can  act  if  one  of  the  5,’s  can  act  without  exceeding 
the  time  bounds  of  the  other  S/s.  This  happens  if  there  is  a  state  70  in  which  the  program  is  simply 
the  Si  that  performs  the  the  transition.  Thus,  the  rule  for  cobegin  is  roughly: 

If 

7.5  =  cobegin  Si//  •  •  •  //Si//  ■  ■■  //Sn  coend, 

7-5'  =  cobegin  S 1//  •  ■  ■  //S',//  ■  ■  ■  // Sn  coend. 

where  370, 7o  such  that: 

7o -S  =  Si 

70  is  otherwise  the  same  as  7 

7o  *"*  7o 

No  other  component  of  7 .5  is  required  to  act  before  7 '0.T 

S'i  =  l'o-S 

7'  is  otherwise  the  same  as  7q 
Then  7  <— >•  7' 

Of  course,  the  English  antecedents  are  made  formal. 

Idle  actions  are  described  by: 

If 

■y'.T  >  7 .r 

7.5  is  not  required  to  act  before  7 '.T 

7'  is  otherwise  the  same  as  7 
Then  7  <— *•  7' 

One  important  consequence  of  using  a  structural  operational  semantics  is  that  7  <—  7'  iff  there 
is  a  proof  of  7  <— ►  7'  from  the  operational  rules.  These  proofs  can  be  regarded  as  formal  objects, 
and,  in  particular,  we  can  do  induction  on  the  proof  that  7  <— ►  7'.  Many  of  the  basic  lemmas  used 
for  soundness  proceed  by  such  inductions. 

This  discussion  omits  subtleties  that  are  essential  to  the  proof.  For  the  model  construction,  the 
actual  proof  rules  assign  responsibility  for  the  transition,  so  that  when  we  define  Tig  we  can  ensure 
that  S  takes  all  the  transitions  in  .  Roughly,  a  subterm  S'  of  the  program  7. 5  is  responsible  for 
the  transition  7  t—>  7'  if  S'  appears  as  -fo.S  in  the  proof  of  7  t-»  7'  or  if  the  transition  is  idle.  The 
determination  of  which  processes  are  finished  requires  some  care.  For  example,  done  is  a  finished 
atomic  process,  but  there  are  also  others,  such  as  cobegin  done^done  coend.  While  the  intuition 
is  reasonably  straightforward,  the  details  are  delicate. 

8In  the  full  proof,  we  use  a  more  standard  SOS  notation,  which  makes  the  structural  induction  dearer  hut  requires 
extra  notation. 
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A. 3  Interpreting  Expressions  and  Formulae 

The  meanings  of  most  expressions  and  formulae  can  be  read  directly  from  the  state  7.  For  example, 
the  value  of  the  expression  x  +  y  in  state  7  is  the  sum  of  7.cr(x)  and  7.a(y).  However,  the  values  of 
control  predicates  at(I)  and  after(l)  depend  on  the  control  state  7 of  the  program,  In  this  section, 
we  sketch  the  interpretations  of  these  predicates  for  the  case  when  l  is  the  label  of  an  atomic  action. 

Let  7  be  a  state  in  an  element  of  Hj.  Interpreting  afier(l)  where  /  is  the  label  of  an  atomic 
action  is  straightforward;  7 .5  includes  a  subterm  of  the  form  /  :  done  if  and  only  if  the  atomic 
action  labelled  /  in  7.5  is  finished. 

We  define  the  set  of  active  atomic  actions  of  a  program  5  inductively;  e.g.,  if  S  is  atomic. 
act(S)  =  {5},  and  e.g. 

act( cobegin 5i//  •  •  •  ^5„coend)  =  [J,  act(S,) 

if  Si  is  not  finished,  actfS'i^)  =  act(.9i) 

if  Si  is  finished,  act(SjS2)  =  act(S2) 

Then  7  \=  at(l)  if  l  is  the  label  of  an  atomic  action  in  act(7.S).  In  the  actual  proof,  we  allow  at(l) 
when  /  is  the  label  of  any  program,  not  just  the  label  of  an  atomic  action.  This  complicates  the 
definition  of  act  somewhat  and  requires  use  of  an  extra  set  of  markers  in  the  operational  semantics. 
However,  it  allows  us  to  verify  the  Proof  Outline  Logic  control  predicate  axioms  without  having 
built  them  directly  into  the  definition  of  7  at(l). 

A. 4  Sanity  Checking 

We  demonstrate  that  the  operational  semantics  and  notion  of  interpreting  processes  are  reasonable 
by  proving  a  series  of  sanity  lemmas.  These  are  lemmas  that  are  not  necessarily  used  in  the 
soundness  proof  proper  but  show  that  the  formal  definitions  derived  from  the  operational  semantics 
agree  with  the  less  formal  ones  used  in  the  body  of  this  paper.  The  following  sanity  lemma,  for 
example,  shows  that  the  intuitive  definition  of  |ot(/)  as  the  last  time  that  at(l)  became  true  agrees 
with  the  formal  definition  of  ja<(/)  as  it  appears  in  the  operational  semantics: 

Let  70  be  a  suitable  initial  state,  and  70  t—  7i  <—  •  •  ••  Then,  for  any  index  i  and 
label  «,  7,. | at(l )  is: 

•  —00  if  (VO  <  j  <  i  :  7j  at(l)) 

•  7 j.T  if  j  is  the  largest  0  <  j  <  i  such  that  (7;_i  ot(l)  and  \=  at(l)). 

•  70 .T,  if  neither  of  the  preceding  conditions  obtains;  that  is,  if  70  )=  at(l)  but 
( :  7j  at(l)  A  7J+1  j=  af (/)). 

That  is,  the  time  that  the  bookkeeping  mechanism  gives  for  To/(/)  is  in  fact  the  value  of  the  clock 
on  the  most  recent  instant  that  at(l)  became  true. 

A. 5  Soundness 

Once  the  SOS  rules  have  been  constructed  and  their  sanity  checked,  it  is  a  routine  matter  to  show 
soundness  of  all  the  Real-Time  Proof  Outline  Logic  axioms  and  proof  rules.  We  define  the  model 
in  the  following  way.  We  consider  executions  starting  with  S  in  an  arbitrary  state  of  control 
and  memory.  We  allow  other  processes  in  this  initial  state  as  well.  We  thus  consider  executions 
that  start  with  some  program  that  includes  S ;  we  run  this  program  for  a  time  (which  gives  an 
arbitrary  state,  perhaps  with  S  partially  executed).  However,  in  the  sequences  in  Hi; .  only  S  is 
allowed  to  take  steps,  so  S  must  be  responsible  for  each  transition. 
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•  7  is  an  initial  state  for  5  iff  7.5  includes  5  as  a  subprogram,  and  7-f at(l)  and  ■).} after H)  are 
initialized  properly.  That  is,  7.| cp  ~  7 .T  if  7-5  (=  cp,  and  to  — oc  otherwise,  for  cp  a  control 
predicate. 

•  Hs  is  the  set  of  all  sequences  (70,71,  •••)  such  that  7  <—  *  70  for  some  initial  state  7.  and 

7,  *  7,+1  for  every  i,  and  5  is  responsible  for  each  transition. 

Note  that  Pig  is  suffix-closed;  that  is,  if  (70,71,  •  •  •  ,7i,7i+i, •  •  •)  G  'tig,  then  also  (7,, 7i+i,  •  •  •)  G  Pig  ■ 

To  prove  the  Control  Predicate  Axioms  of  Figure  1  sound,  we  characterize  possible  control 
states  of  a  program  and  possible  executions  of  a  program.  For  example,  omitting  labels,  done  5  is 
a  possible  subterm  of  a  control  state  (as  skip  5  can  evolve  into  it);  but  5  done  is  not  possible  (the 
first  in  a  sequence  of  commands  is  executed  before  the  second). 

Similarly,  we  say  that  program  fragment  S'  is  a  descendant  of  5  if  (roughly)  there  are  states 
7  <—  *  7'  such  that  7.5  =  5  and  7'. 5  =  5';  it  is  a  proper  descendant  if  5  ^  S'.  We  characterize  the 
descendants  of  all  terms.  For  example,  let  5  be  a  command  sequence  l  :  ((m  :  S  i)(n  :  S  2)).  and  S' 
be  a  descendant  of  5.  Then  there  is  at  most  one  subterm  of  S'  labelled  /,  and  it  must  be: 

•  l  :  ((m  :  S[)(n  :  S2))  where  5(  is  a  descendant  of  5 1,  or 

•  l  :  (n  :  S'2)  where  S'2  is  a  proper  descendant  of  5 2. 

Soundness  of  the  Control  Predicate  Axioms  follow  easily  from  these  characterizations.  For 
example,  for  one  direction  of  the  axiom  for  sequencing,  after(m)  —  at(n ),  we  calculate  that  if 
7  |=  after(m),  then  there  must  be  a  subterm  m  :  done  of  7.5.  From  the  preceding  characterization, 
this  means  that  n  :  S2  must  also  be  a  subterm  of  7-5;  and,  by  the  definition  of  £»<(•),  this  implies 
that  at{n )  holds  as  well. 

The  other  axioms  and  proof  rules  are  proved  similarly.  For  example,  to  show  (22),  we  show  by 
induction  on  the  proof  of  7  <— ►  7'  that 

(7  *— •  7')  =>  (7-7"  <  l' -T)  (15) 

Suppose  that  70  7i  •  •  •  is  a  sequence  of  transitions  from  an  initial  state.  By  induction  on  i 

and  the  definition  of  initial  state,  we  show  that  7i.|at(/)  and  ji.]after(l)  are  either  -oo,  or  ~ij.T 

for  some  j  <  i.  This  and  (45)  suffices  to  show  (22). 

Axioms  and  rules  involving  proof  outlines  require  verifying  statements  of  the  form  'big  f=  /=>□/. 
From  temporal  logic,  we  know  that,  if  7  =>  Q)I  is  valid,  so  is  I  =>  □/.  /  is  a  predicate  logic  formula 
rather  than  a  temporal  one,  hence  it  is  true  or  false  in  a  single  state.  It  thus  suffices  to  show  that, 

for  each  7  «-**'  70  >  71  where  7  is  an  initial  state  for  5,  if  70  \=  I,  then  71  [=  I. 

We  use  this  method  to  verify  each  proof  outline  axiom  and  proof  rule.  All  these  verifications 
proceed  by  induction  on  the  proof  of  the  transition  70  ■— -  7i-  For  example,  to  check  skip  Axiom  (7). 
let  5  =  /  :  skip.  Ipo{S)  =  (<**(/)=>  P)  K  (after(l)  =>  P),  where  Pis  primitive.  Suppose  70  \=  Ipo{S)- 
It  is  easy  to  show  that  7  )=  P  is  independent  of  7 .5  and  7 .T  if  P  is  primitive.  The  proof  comprises 
the  following  cases: 

1.  The  transition  is  idle,  and  70  \=  at(l).  As  70  j=  Ipo(S)i  we  conclude  70  P.  In  this  case, 
the  only  component  of  71  that  is  different  from  70  is  71. T.  Since  the  value  of  a  primitive 
formula  does  not  depend  on  7 .T,  and  since  70  P,  we  conclude  77  |=  P.  This  suffices  to 
show  7j  (=  Ipo(s). 

2.  The  transition  is  idle,  and  70  i=  afier(l).  The  proof  proceeds  as  above. 
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3-  The  transition  is  not  idle,  in  which  case  it  proceeds  by  SOS  rule  for  skip  above.  That  is, 
7o-S  =  /  :  skip,  71 .5  =  l  :  done,  and  70  and  7t  are  otherwise  identical  except  possibly  for 
7 ,.T.  Note  that  70  P,  because  70  }=  at{l)  and  70  |=  Ipo(S)-  Primitive  formulas  do  not 
depend  on  the  changed  components.  Hence  77  j=  P  and,  thus,  71  (=  Ipo(s )  as  desired. 

4.  7o  |=  -1  {at(l)  A  after(l)).  In  this  case,  S  cannot  be  responsible  for  any  non-idle  transitions, 
and  all  transitions  are  thus  idle.  In  particular,  71  |=  -^(at(l)Aafter(l)),  and  hence  77  j=  1  po{S) 
vacuously. 

Each  of  the  other  axioms  and  rules  of  Real-Time  Proof  Outline  Logic  is  handled  in  a  similar 
manner,  and  thus  we  establish  soundness.  The  subtle  part  of  the  proof  is  not  checking  these  rules, 
so  those  details  are  omitted  here.  The  subtle  part  is  the  definition  of  the  real-time  execution  model 
that  is  explained  above. 
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